\chapter{Inleiding}
\label{Inleiding}
\section{Achtergrond}
\subsection{Dynamische Websites}
Tegenwoordig zijn er steeds meer dynamische websites te vinden op het internet. Dynamisch op verschillende manieren, 
enerzijds omdat de data die getoond wordt afhankelijk kan zijn van gebruiker tot gebruiker, en anderzijds kan de actieve 
gebruiker ook zelf inhoud toevoegen aan websites. Dit in tegenstelling tot de statische websites, 
waarbij kant-en-klare HTML-pagina's op de webserver staan te wachten om opgevraagd te worden door een gebruiker.

\subsection{Web Mashups}
Een aansluitende trend is het toenemend aantal web mashups, 
waarbij een website \textit{(de integrator)} functionaliteit en/of gegevens van derden toevoegt \textit{(third party componenten)}. 
Dit om als resultaat een nieuwe flexibele client-side applicatie te verkrijgen, met de bedoeling een toegevoegde waarde te bieden. 
Bijvoorbeeld een formulier waar een adres ingegeven moet worden. Vroeger werd dit meestal gedaan door een input veldje
waar men plain text moest invoeren met o.a. straat, plaats,..
Dit kan nu bijvoorbeeld worden vervangen door gebruik te maken van een google maps plugin.
In dit geval is de website met het formulier de integrator, en de google maps plugin de third party component.

\pagebreak

\subsection{JavaScript}
Buiten de server-side webtalen \textit{(E.g. PHP)} is er binnen deze opstelling ook een client-side programmeertaal van belang, 
JavaScript genaamd. JavaScript code kan meegestuurd worden in de HTML-pagina om op de client-side uit te voeren.
Dit om bijvoorbeeld een meer interactieve web ervaring aan de gebruiker te bieden. 
Ook communicatie tussen verschillende componenten is mogelijk via JavaScript, 
eventueel beperkt door de Same-Origin Policy (zie Sectie \ref{Same_Origin_Policy}).


\section{Security Requirements}
Een nadeel van het gebruik van third party componenten is dat een third party component mogelijk onbetrouwbaar is.
Deze kan zelf ook JavaScript code uitvoeren op de client side. 
Bijvoorbeeld IGoogle (Figuur \ref{igoogle}) is een bekend voorbeeld van een web mashup. 
Men kan allerlei componenten toevoegen \textit{(e-mail, weerbericht, nieuwsberichten, ..)}, 
waarbij weersvoorspellingen of nieuwsberichten bijvoorbeeld gebaseerd kunnen worden op locatie. 
Daarintegen is het niet wenselijk dat deze componenten emails kunnen lezen, laat staan ze kunnen aanpassen.
Er is nood aan een least privilege principe, waarbij elke component beperkt is tot de functionaliteit
die deze nodig heeft om zijn eigen taken te kunnen uitvoeren. Bovendien is deze nood toegenomen, 
voornamelijk door de mogelijkheden van de nieuwe HTML5-specificaties\cite{intohtmlv}. Zo zal het mogelijk zijn om via JavaScript o.a. 
de geolocation van de gebruiker te raadplegen, audio en video op te nemen, data op te slaan en op te halen aan de client-side, 
te communiceren met verschillende windows en zelfs met externe servers. Dit maakt het uitvoeren van een potenti\"ele aanval veel interessanter, zelfs als het script beperkt is tot het uitvoeren binnen zijn eigen origin (zie Sectie \ref{Same_Origin_Policy}).
	\begin{figure}
		\centering
 		\includegraphics[width=0.80\textwidth]{img/igoogle.jpg}
 		\caption{Voorbeeld web mashup: IGoogle  \textit{(http://www.google.com/ig/})}
 		\label{igoogle}
	\end{figure}

\section{Current state of practice}
Het idee achter web mashups is dus om meerdere componenten te integreren en hun code, 
data en/of uitvoeringsresultaten samen te mengen. Er bestaan verscheidene (al dan niet gratis) verkrijgbare web applicaties, 
die APIs beschikbaar stellen om als component te kunnen gebruiken in web mashups.
Om deze mashup mogelijk te maken moet de mashup integrator de nodige glue code voorzien om eigen componenten en 
third party componenten op de pagina te kunnen laden en ze eventueel te laten samenwerken. Hiervoor worden 2 technieken onderscheiden, 
Script inclusion en Iframe integration.

\subsection*{Same-Origin Policy}
\label{Same_Origin_Policy}
De same-origin policy is het standaard beveiligingsconcept voor de client-side programmeertalen dat in alle huidige browsers aanwezig is.
De same-origin policy scheidt code over verschillende uitvoeringscontexten gebaseerd op hun origin. 
Een origin is gedefinieerd als een triple bestaande uit; een domeinnaam, applicatie laag protocol en poortnummer (bv. (www.voorbeeld.be, http, 80)). 
De same-origin policy laat nu toe dat stukken code die van dezelfde origin afkomstig zijn, hun context volledig delen. 
D.w.z. dat ze aan elkaars functies en inhoud kunnen. Als stukken code verschillende origins hebben kunnen ze dit niet. 
Dit dient om te voorkomen dat er gevoelige data van andere sites kan gestolen worden zoals bijvoorbeeld cookies of login gegevens. 
Ook het sturen van requests naar de server is niet mogelijk vanuit een andere origin (zie Figuur \ref{SOP_example}).

	\begin{figure}
		\centering
 		\includegraphics[width=0.80\textwidth]{img/SOP_example.jpg}
 		\caption{Same-Origin Policy voorbeeld: Website a met iframe b}
 		\label{SOP_example}
	\end{figure}
	
\pagebreak

\subsection{Script inclusion}
HTML script tags worden gebruikt om JavaScript te laten uitvoeren tijdens het laden van de webpagina. 
Deze code kan afkomstig zijn van een andere server dan de server die de webpagina inlaadt \textit{(integrator)}.
Dit wil zeggen dat de browser de code zal uitvoeren alsof het van dezelfde origin afkomstig is dan de code van de integrator zelf, 
zonder enige beperking van de same-origin policy. De ge\"integreerde code zal uitgevoerd worden in dezelfde JavaScript context, 
d.w.z. toegang krijgen tot de volledige inhoud van de webpagina waarin het wordt uitgevoerd. 
Alle gevoelige JavaScript functionaliteiten die toegankelijk zijn voor de pagina waarin de code uitgevoerd wordt, 
zullen ook toegankelijk zijn voor de ge\"integreerde code.

\subsection{IFrame integration}
HTML iframe tags kunnen worden gebruikt om een document in te laden in een andere frame. 
Het ge\"integreerde document wordt in zijn eigen omgeving ingeladen net alsof het in een apart browser window geladen zou worden.
Het voordeel bij het gebruik van iframe integration is dat ge\"integreerde componenten met verschillende origines ge\"isoleerd zijn
van elkaar dankzij de same-origin policy. De code die in de frame uitgevoerd wordt zal wel nog steeds aan dezelfde gevoelige JavaScript functionaliteiten
geraken als de pagina waarin het ge\"integreerd wordt, al zijn deze beperkt tot hun eigen context.
De third party component zou bijvoorbeeld gebruik kunnen maken van de local storage APIs,
maar zal enkel toegang hebben tot de local storage van zijn eigen origine.

\section{Current state of the art}
Momenteel bestaan al reeds enkele technieken die een oplossing bieden voor de vooropgestelde security requirements. 
\subsection{CaJa, AdSafe}
CaJa\cite{caja} is gebaseerd op de principes van object-capabilities. 
Door het verwijderen van problematische JavaScript features \textit{(zoals prototypes)} en DOM APIs\textit{(innerHTML)}. 
Dit moet leiden tot het scheiden van componenten ongeacht het domein. Ze kunnen nog communiceren via expliciet gedeelde objecten,
die betrouwbaarheid en integriteit aanbieden. Ook ADsafe \textit{(waarop CaJa gebaseerd is)} gebruikt zo'n techniek.
Ze laten wel bepaalde onveilige functionaliteiten\cite{cajalimit} niet toe zoals \textit{eval} en \textit{with}, 
ook het gebruik van \textit{this} is verboden omdat het properties heeft die referenties naar het global Object kunnen lekken (met de referenties naar de originele functies). 
Dit is een van de belangrijkste nadelen van deze aanpak.

\subsection{WebJail, Conscript}
WebJail\cite{webjail} en Conscript\cite{conscript} hebben een andere opstelling, hier hoeft geen code herschreven te worden. 
WebJail laat toe de integrator een policy aan een ge\"integreede component op te leggen. 
Er wordt gebruik gemaakt van een extra laag tussen de uit te voeren code en de browsercode die de uiteindelijke JavaScript code 
gaat uitvoeren \textit{(waar dit bij CaJa door object-capabilities werd gedaan)}. Het prototype van WebJail is een Add-on voor Firefox, 
en dit is het grote nadeel. Het volstaat niet dat de integrator policies oplegt aan de externe component, 
de client moet ook de add-on ge\"installeerd hebben met de aangepaste versie van Firefox.

\section{Doelstellingen}
Het doel van deze thesis is om een manier aan te bieden om veilig externe componenten te integreren in web mashups,
zonder de gekende nadelen van de huidige implementaties. 
Het moet mogelijk zijn voor de integrator om de policy te bepalen die op de externe component moet worden toegepast. 
Belangrijk hierbij is dat de third party component niet aangepast moet worden om te kunnen werken, 
alle onveilige functies blijven bestaan indien gewenst. Afblokken van functionaliteiten moet kunnen gebeuren op een veilige manier, 
alle paden naar dezelfde functie moeten hetzelfde resultaat geven. \textit{(E.g. XMLHttpRequest / document.XMLHttpRequest)}. 
Het prototype mag ook geen aanpassingen aan de client side vragen,
m.a.w. de client moet niets extra installeren of aanpassen en merkt het verschil niet tussen de website met of zonder het prototype. 
Het is de bedoeling dat er een least privilige principe kan afgedwongen worden door de integrator, 
zodat enkel de nodige functionaliteit uitgevoerd kan worden. 

